Subject: F/C Curveball...

From: "Shannon Nix" <[email-masked]>
Date: Fri, 16 Dec 94 10:11:08

Hi all,
          
          I'm inclined to agree with Paul on this one.  In fact, the 
          original proposal required an IPM to start data flow.  
          
          However, when this was discussed as a group, the consensus among 
          implementers was that they wanted the flexibility to send grants 
          at various points in the circuit establishment.  Unfortunately, 
          this flexibility came at the expense of all other implementers 
          having to distribute their receive-grant-logic all over the place. 
          To my recollection, this "down-side" was not considered during the 
          discussion of this "feature".

          What do others think?  
          
          How many implementations are sending grants on circuit control 
          messages?
          
          Are all implementations prepared to receive grants at any time?  
          If so, did this create complexity?
          
          Best regards, Shannon

          With regard to Pandian's suggestion of an implied initial window size.
          I believe it destroys the determinism of the protocol AND is not
          needed because the messages for which the implied grant was suggested
          are not subject to F/C.

______________________________ Reply Separator _________________________________
Subject: Flow Control curve ball...
Author:  [email-masked]
Originator: 
[email-masked] at Internet-Gateway
Date:    12/14/94 9:55 AM

A very last minute thought on Flow Control...

Currently the Flow Control flags may be piggy-backed on almost all message 
types, not just on INFOFRAME or DGRMFRAME messages.  This has the 
unfortunate effect of making it difficult to architect a separate 'data 
forwarder process' for each circuit that handles only the golden path data 
traffic as it cannot have sole responsibility for Flow Control.

I'll confess an interest in this - we do have such a data forwarder and 
would like to be able to achieve the clean functional separation of putting 
all Flow Control responsibility in this process.  I don't believe this would 
be a performance problem even though it would mean that the grant of the 
initial window would flow as an independent flow control message.  Once into 
data flow (I or UI frames) there would be no difference to the Flow Control 
mechanism.

We believe this would be a significant improvement on the architectural 
cleanliness of DLSw, but recognise that it is very much a last minute 
thought for V1 (though it actually requires only relatively little change to 
the document - basically just change the list of permitted frames for Flow 
Control piggybacking and mandate that a RESTART_DL implies either a Reset 
Window or reverts to the initial state).

Is there any interest in doing this for V1 (I'm willing to do the 
appropriate wordsmithing for Alan), or should we consider it in V2 instead?

Paul Brittain
Data Connection